This sentence (while "accurate", I think) doesn't make much sense... I am not sure how to improve it without re-working the entire section.

"During detection, order definitions MUST be resolved into individual buildpack implementations. If present, Image Extensions MAY provide an order definition. Buildpacks MUST provide an order definition."

Not sure if that covers the intent.. which itself kinda hints the original still has wiggle room.. (It's possible in my rephrasing to interpret that each extension would supply an order definition, or that there would be one for all extensions).

The original leaves bare the possibilty that an order defintiion for extensions is required, although the extensions themselves remain optional (as the binding of the 'if present' can be made to 'image extensions' rather than 'order definition').

Can we stop using the term "buildpack implementation"? Or at least swap the word order to "implementation buildpack" if we can't think of a better term for a non-meta-buildpack? Meta-buildpacks are still implementations of buildpacks, so I think it's difficult to understand these sections.

This could be a separate PR, but I feel like adding image extensions makes this even more confusing.

Some name ideas:

• atomic buildpacks
• executable buildpacks
• concrete buildpacks

I like concrete buildpacks.. has a nice construction theme to it ;p

Please see #300 - I went with "executable buildpack" because that seemed most natural according to the definition I used.

To make this more clear, I think we should define the following six terms early in the spec:

1. Order buildpack
2. Atomic buildpack
3. Order image extension (not currently allowed)
4. Atomic image extension
5. Order build module (currently only order buildpack)
6. Atomic build module (atomic buildpacks and image extensions)

The names are just suggestions.
Maybe it's easier to say that image extensions are buildpacks?

1. Normal order buildpack
2. Normal atomic buildpack
3. Image extension order bulidpack (not currently allowed)
4. Image extension atomic buildpack
5. Order buildpack (only normal buildpacks allowed)
6. Atomic buildpack (atomic normal and extension buildpacks)

@sclevine what is a build module? What is the difference between an order build module and an atomic build module?

Let's hash this out in https://github.com/buildpacks/spec/pull/300/files - we can rebase this PR when that one is merged.

Curious why image extensions MUST be optional?

@sclevine could you elaborate?

How/where will we be enforcing this?

The same way we enforce buildpacks not writing to other buildpacks' layers directory (wishful thinking) :)

This is something that we could add in theory, but it would to subject to the same concerns outlined in buildpacks/rfcs#155

Why not?

Linking to discussion here: https://github.com/buildpacks/rfcs/pull/173/files#r794629405

The concern is that we could end up switching to a base image that doesn't have buildpacks on it.

I would rather have this as a 'SHOULD' than a MUST.. it's doable, IF you really know what you are doing, and closing that door with a MUST might end up closing an escape hatch that someone might need =)

I've tried swapping build images in the PoC (and copying the /cnb folder from the previous image via multistage) and it is doable, but I hit odd issues executing the build step after the extension step, that I suspect were related to that switch.. I suspect with enough care, with certain constraints it could be done.. eg, if the image switched to was built as a stack image that includes the buildpacks content, etc, etc, etc.

What will happen in case this label is set to true? What are the cases when an extension ran and the output image is still rebaseable?

One other thing I am unsure about is how we will uniquely identify a "family" of base images that can be rebased with one another.

I know we thought about replacing stack id with some other identifier that indicates the "family" of base images - how does that fit in here?

The whole rebase picture with extensions is still unclear to me. It would be nice if we can have some actual examples of cases where/how this can work with platforms like pack or kpack.

I'm thinking / hoping that an extension can still set rebaseable=true, where it modifies the build image (say to install runtimes, tools to build etc) .. but limits the runtime changes to just using 'FROM' to switch to a different run image.. I think this would still qualify to be rebaseable, as future run images can still be swapped in.. provided they still contain the required dependencies that were met by the substituted run image. In theory this allows for the existence of a generic builder image that tailors itself to install runtimes/tools etc, working in conjunction with a set of run images to cover the most common scenarios.. and maybe, also in conjunction with a generic (non rebaseable) run image to cover the edge cases where the common image was insufficient.

I wonder, in the case where a Dockerfile is applied to the run image, but all it does is switch the run image (using a FROM instruction):

• Should we publish a new "extended" run image (the <target-image> argument provided to the extender)
  • Opinion: no, that seems confusing
• Should we run genpkgs?
  • Opinion: no, but we should make an effort to locate an sbom for the new run image (see Allow platforms to provide run image sboms rfcs#211)